There are a variety of conventional technologies that can be used to integrate applications with one another. However, most, if not all, of these technologies are not optimally suited for organizations that have larger numbers of orchestrations, competing initiatives, and resource limitations.
In a more basic integration environment, one application does not know how to communicate with another application. For example, one entity can have a data application that generates financial data and needs to have the financial data represented in various reports. Another entity can have a report application for generating reports from financial data. However, the one entity may not know how to communicate financial data from the data application to the report application at other entity. To solve the communication problem, code for either or both of the application and the other application can be redesigned and recompiled to communicate with one another. Code redesign can be relatively simply, such as, for example, using a Dynamic Link Library (“DLL”) configured to convert between the output of the data application and the input of the report application.
Even though code redesign is relatively simple, at larger scales and in more complex environments, code redesign can be costly and can significantly burden application developers and designers. For example, as a company grows it can use disparate data generation applications, reporting applications, payroll processing applications, accounts receivable applications, accounts payable applications, point-of-sale (“POS”) applications, etc. Each of the applications are potentially owned by different entities and designed with different expectations. Some or all of these applications may need to communicate with one another to facilitate solutions for the entity. Thus, each time the requirements of one application change, many other applications must be redesigned to account for the changed requirements. As the number of applications used by an entity grows, the difficulties, required resources, and costs associated with maintaining communication between the applications further increases (potentially approximating exponential growth).
Further, some entities may have multiple applications designed to solve the same problem in different ways and/or in different geographic locations. For example, when one entity purchases another entity, the purchasing entity may inherit applications from the purchased entity. The purchasing entity may desire to set up a centralized system for all back office solutions. As such, the purchasing entity has to integrate redundant and/or disparate applications into a central application solution. The central application solution can include potentially hundreds of unique integrations and must be maintained as application requirements of individual applications change over time.